1. Field of Invention
Embodiments of the invention relate generally to the software arts, and, more specifically, to a method and a system for obtaining and modifying Web components such as portlets.
2. Background
Many organizations implement an enterprise portal to host internal and external applications. A portal is an application which aggregates portlet applications together in a presentable format. Beyond merely being a presentation layer, a portal typically allows users to customize their presentation, including what portlet applications to display. A portal can also provide a convenient single sign-on mechanism for users. Single sign-on allows access to all applications once a user logs into a portal, that is the user does not have to log into every application separately.
A portlet is an individual Web component that is made accessible to users via a portal application. Typically, a single portlet generates only a fragment of the markup that a user sees from a browser. Users issue requests against portlets from a portal page. The portal in turn forwards those requests to a portlet container, which manages the lifecycle of a portlet. The portlet container is part of the portal application. The portlet container provides the run-time environment to portlets, much in the same way a servlet container provides the environment for servlets. The portlet container manages portlets by invoking their lifecycle methods. The portlet container forwards requests to the appropriate portlet. When a portlet generates a response, the portal renders it to the user. The sequence of events results in the user's portal page.
Portlets and servlets have a number of similarities. A servlet is an object that receives a request and generates a response based on that request. Portlets are similar to servlets, in that: 1) portlets are managed by a specialized portlet container; 2) portlets generate dynamic content; 3) a portlet's life cycle is managed by the portlet container; and 4) portlets interact with a client device via a request/response paradigm. Portlets are different from servlets, in that: 1) portlets only generate markup fragments, not complete documents; 2) portlets are not directly Uniform Resource Locator (URL) addressable; and 3) portlets cannot generate arbitrary content, since the content generated by a portlet is going to be part of portal page.
Portlets also have access to additional functionality such as: 1) portlets ways to access and store persistent configuration and customization data; 2) portlets have access to user profile information; 3) portlets have URL rewriting functions for creating hyperlinks within their content, thus allowing the portal server agnostic creation of links and actions in page fragments; and 4) portlets can store transient data in the portlet session in two different scopes: the application-wide scope and the portlet private scope.
However, portlets do not have access to the following functionality provided by servlets: 1) setting the character set encoding of the response; 2) setting Hypertext Transfer Protocol (HTTP) headers on the response; and 3) the URL of the client request to the portal.
A portlet container is very similar to a servlet container, in that every portlet is deployed inside a portlet container that controls the life cycle of the portlet and provides it with necessary resources and information about its environment. A portlet container is responsible for initializing and destroying portlets and also for passing user requests to the portlet and collecting responses from the portlet. The portlet container also provides persistent storage for portlet preferences.